Currently, user authentication is accomplished in at least two ways: 1) user identification (“ID”) and password or 2) ITU-T X.509 certificates, ITU-T Recommendation X.509, published August 1997. In addition, large web sites often provide the same content on multiple web servers and use Domain Name Service (“DNS”), Internet Standards Track Standard 0013, STD0013-Domain Name System, published November 1987; round robin; or other technology to redirect user requests to one of the many servers. The use of multiple web servers is done to balance the load on the web site and provide the ability to take a server offline for maintenance or add servers during high load periods. In existing systems a user is prompted for authentication information, for example, user ID and password, each time the user hits a server the user has not yet visited.
FIG. 1 illustrates a simplified network flow diagram of existing user ID and password authentication systems. In FIG. 1, user workstation 10 is connected to web site A 40 via the Internet 30 and Internet Service Provider (“ISP”) 20. Web site A 40 is comprised of multiple web servers a, b, c and d 41, 42, 43 and 44, respectively. Web server a 41 is shown coupled to web server b 42 via a first communication line segment 45, web server b 42 is in turn coupled to web server c 43 by a second communication line segment 46, web server c 43 is in turn coupled to web server d 44 by a third communication line segment 47, and web server d 44 is in turn coupled to web server a 41 by a fourth communication line segment 48 to complete the network.
To access secure web site A 40 or a secure page on a web site A 40, in FIG. 1, the user first establishes an Internet connection using an Internet browser program (for example, Netscape Communicator® or Microsoft Internet Explorer®) which is running on user workstation 10. Netscape Communicator® is licensed by Netscape Communications Corporation of Mountain View, Calif. Microsoft Internet Explorer® is licensed by Microsoft Corporation of Redmond, Wash. Once connected to the Internet, the user requests access to web site A 40 by entering the Universal Resource Locator (“URL”) for the home page of web site A 40 in the address block of the Internet browser program. After web site A 40 receives the user's connection request, the request is routed to an available web server, for example, web server a 41, which sends a prompt for the user to enter a user ID and password. After the user enters and sends the user's user ID and password to web server a 41, web server a 41 validates the user ID and password and establishes a connection between the user's browser at workstation 10 and the requested home page of web site A 40. As the user moves through web site A 40 it frequently becomes necessary for the user to connect to a new web server. When this happens, the new web server, for example, web server b 42, receives a request to connect to the user. The user is required to re-enter and send the user's user ID and password to web server b 42 for validation prior to establishing a connection between the user's browser at workstation 10 and the requested page at web server b 42. In the system in FIG. 1, the user may need to enter the user's user ID and password up to four separate times at web site A 40 to logon to each of the four web servers.
A prior art alternative to constantly requiring the user to re-enter the user's ID and password is to use X.509 certificates. These “certificates” are encrypted electronic signatures provided by a Certificate Authority (“CA”) that certify the identity of the user. Certificates are used by some web sites to provide user authentication and, while certificates do not require the re-entry of the user ID and password each time the user contacts a new server, certificates do require a trusted third party to “certify” the identity of the user. This trusted third party is the CA, such as, VeriSign, Inc. of Mountain View, Calif. The challenge with a certificate system is finding a common third party that both the user and the server trust. Another alternative is for the web site owner or Internet Service Provider (ISP) to issue the certificates themselves. Unfortunately, setting up and running a CA is neither a trivial nor a problem free task. In addition, once a company sets up the CA, it may find that other entities are using the company's certificates for authentication, as a result of the company's status and reputation. Additionally, revocation technology and the infrastructure for certificates is still being developed.
FIG. 2 illustrates a network diagram of an exemplary user certificate authority authentication system. FIG. 2 is identical to FIG. 1 except, in FIG. 2, a CA 50 is connected to the Internet 30 and can communicate with both the user workstation 10 and web site A 40.
In CA systems the initial user logon and traversal of the web site are essentially identical to the description provided for FIG. 1. As in the process outlined above for FIG. 1, when web server a 41 receives the user ID and password, web server a 41 sends the user ID and password to the CA 50 and requests a certificate validating the identity of the user. Once the CA 50 validates the user ID and password, the CA 50 creates a certificate and sends the certificate back to web server a 41. Web server a 41, in turn, sends the certificate to the user and then connects to the user. Another difference occurs when a new web server, for example, web server b 42, needs to be accessed. Once web server b 42 receives the access request, web server b 42 reads and validates the user's certificate and establishes a connection between the user's browser at workstation 10 and the requested page of web site A 40 without requiring the user to re-enter the user's user ID and password again. However, if the certificate is not valid, then, web server b 42 must obtain a new certificate before connecting to the user. While this certificate system is an improvement over the basic ID and password system of FIG. 1, the certificate system now requires that a third party or an additional and expensive local certificate system generate and certify the user certificates.
While current systems may use cookies to identify users, there are none that use the cookie to pass user credentials between servers nor are any of the current systems capable of working across multiple, separate enterprises.
Therefore, what is needed is a system that is simpler to implement and administer than ID and password or certificate systems, can only be used by the company or group that created the system, enables the passing of user credentials between multiple, separate enterprise servers, permits the immediate revocation of user authentication and access and is useable from any computer capable of Internet access without the user having to hand carry a special key or token to each computer.